Virtual Root

Virtual root is an optional feature that allows users to connect to a Folder or Plan object. This limits the scope of what the user can see on the Scheduler system, primarily in the way of objects and instances.  Virtual root limits visibility and accessibility, but not functionality.

 

Note: As a best practice, use a Folder when connecting to a virtual root. While you can connect to a Plan, this is supported for backwards compatibility purposes.

 

When connecting to a Folder or Plan, the user will see all the connection point's child objects and nested child objects in the Object Navigation pane. They will not see any objects at the same connection level, or higher - and therefore won't be able to access them. In addition, for any objects that generate instances (Jobs, Plans and references), users will only see instances within the virtual root connection point. This applies to all the views that display instance data (e.g. Daily Activity, Operations, Instances, Runbook, etc.).

 

If an out-of-scope object (e.g. a Queue, User Account, etc.) is used in a Job, the Job will still function as expected (e.g. it will run on the out-of-scope Queue, even if you don't have access to it due to a virtual root connection). But, as a best practice, shared objects should be accessible to Job authors, and therefore be child objects within the virtual root connection point.

 

If a variable is defined outside of a virtual root connection, the variable will resolve as designed. In addition, you will also see the variable in the Variable Explorer pane.

 

To create a virtual root connection, use the Connection Manager to set this up. Press F4 or click on the ActiveBatch menu item, then select Connect. The Connection Manager dialog will appear. In the Job Scheduler field, enter the Job Scheduler name, followed by a forward slash, then enter the full path to the Folder you wish to connect to. The Folder can be any Folder, either at the root of the Scheduler, or nested within another container. See the image below as an example.

 

Note: See Publishing a Container if you wish to learn about what is required to connect to a virtual root using a published Folder.

 

 

Click the Connect button to connect to the virtual root. Once connected, only child objects (and nested child objects) within the connection point will be visible in the Object Navigation pane. In this example, the virtual root connection is using the IT Jobs Folder as its connection point.

 

In the figure below, the leftmost image depicts a Scheduler root connection, and the rightmost image depicts a virtual root connection.

 

 

When connected to the virtual root, you only see the contents of IT Jobs. You do not see the other Folders at the same level as the connection point. You also do not see the "RootJob". You do see the built-in objects (OnDemand, RuntimeQueue and RuntimeUserAccount), and that is by design. In addition, for any objects that generate instances, you will only see the instances created within your virtual root connection, when using the various instances views.

 

If, for any reason, objects within the virtual root connection reference associated objects outside of the virtual root connection, you will see what is depicted in the image below - when looking at the property of the shared object(s) that are out-of-scope. Of course, the Job author who created the Job must have had access to all the objects, because they would not have been able to see or access the out-of-scope shared objects if they had connected to the virtual root.

 

Notice there is a dollar sign in front of the Queue and User Account. This is prefixed to the object name as a visual aid for you to know the objects are not within the virtual root connection point. In addition, if you click on the ellipsis to attempt to view the properties of the Queue and User Account objects, you will not be able to see them, as per the error message in the image below. This is by design. However, as stated above, visibility and accessibility are limited when using virtual root, but not functionality. Therefore, when triggered, the Job will run as expected, using its assigned Queue and User Account.

 

 

In continuing with this example, it would be a best practice to add a shared objects Folder that is visible within the user's virtual root connection point. The shared objects Folder should contain the objects that users need to access when building out their various Jobs and Plans. If you do not do this, the Job author will not have access to the shared objects they may need.